1. Technical Field
The present invention relates in general to verifying software and in particular to debugging. Still more particularly, the present invention relates to a system, method and computer program product for performing thread-specific display of breakpoints.
2. Description of the Related Art
With the increasing penetration of processor-based systems into every facet of human activity, demands have increased on the processor and communities to produce systems of hardware and software that are free from design flaws. Circuit products, including microprocessors, digital signal and other special-purpose processors, ASICs, and the software that runs them have become involved in the performance of a vast array of critical functions, and the involvement of computing systems in the important tasks of daily life has heightened the expectation of error-free and flaw-free design. Whether the impact of errors in design would be measured in human lives or in mere dollars and cents, consumers of computing systems have lost tolerance for results polluted by errors. Consumers will not tolerate, by way of example, miscalculations on the floor of the stock exchange, in the medical devices that support human life, or in the computers that control their automobiles. All of these activities represent areas where the need for reliable results has risen to a mission-critical concern.
In response to the increasing need for reliable, error-free designs, the processor and software design and development community has developed rigorous, if incredibly expensive, methods for testing and verification for demonstrating the correctness of a design. The task of hardware verification has become one of the most important and time-consuming aspects of the design process.
A debugger is a computer program that is used to debug (and sometimes test or optimize) other programs. The code to be examined might alternatively be running on an instruction set simulator (ISS), a technique that allows great power in its ability to halt when specific conditions are encountered but which will typically be much slower than executing the code directly on the appropriate processor.
When the program under test crashes, a source-level debugger or symbolic debugger, commonly seen in integrated development environments, shows the position in the original code. If it is a low-level debugger or a machine-language debugger, the debugger shows the line in the disassembly. A “crash” happens when the program can't continue because of a programming bug. For example, perhaps the program tried to use an instruction not available on the current version of the CPU or attempted access to unavailable or protected memory.
Typically, debuggers also offer more sophisticated functions such as running a program step by step (single-stepping), stopping (breaking), which includes pausing the program to examine the current state, at some kind of event by means of breakpoint, and tracking the values of some variables. Some debuggers have the ability to modify the state of the program while it is running, rather than merely to observe it.
The same functionality which makes a debugger useful for eliminating accidental bugs allows it to be used as a cracking tool to learn how to evade copy prevention and other programmed limitations. Debuggers make the debugging process much easier and faster, to the point where the availability of a good one for a particular language and platform can sway the decision to use that language rather than another language that is superior in other respects but lacks such tools.
An important difficulty is that software running under a debugger might behave differently than software running normally, because a debugger changes the internal timing of a software program. That makes it often very difficult to track down runtime problems in complex multi-threaded or distributed systems. As an answer to these difficulties, some graphical system debuggers allow a user to set breakpoints that fire only when the program hits the given breakpoint. On many debuggers these ‘thread-specific’ breakpoints are set by setting a normal breakpoint and then adjusting the breakpoint properties to apply only to the current thread.
While debuggers clearly track that a breakpoint is thread-specific, all prior art debuggers display the breakpoint along side the source without respect to the thread that the user is currently observing. This inability to select breakpoints in a thread specific manner leads to costly confusion in the debug process.